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Description 

Technical Field 

[0001] This invention relates to a recording medium 
management method suitable when used in the case of 
recording digital data to be processed by computer onto 
a magneto-optical disc on which digital audio data is pri- 
marily recorded in compressed manner, or reproducing 
it from such a magneto-optical disc, and to a system and 
to a recording medium using said method. 

Background Art 

[0002] For managing the recording of digital data on 
a recording medium, it is known to provide a TOC (table 
of contents) area, forming a type of first table - see for 
example EP-A2-0 448 378, forming the preamble part 
of claim 1. 

[0003] Recently, mini-discs (MD) (Tradename) using 
magneto-optical disc as recording medium, and adapt- 
ed for compressing digital audio data to record com- 
pressed data thereonto and expanding such com- 
pressed data to reproduce therefrom data correspond- 
ing to original data have been being popularized. Fig. 
29 shows a recording format in this mini-disc. As shown 
in this figure, one circumference of the mini-disc is di- 
vided into a plurality of sectors. One cluster is constitut- 
ed by 36 sectors, and compressed digital audio data is 
recorded with this cluster being as unit. 
[0004] In the case of mini-disc for recording, the lead- 
ing three sectors of one cluster (= 36 sectors) is caused 
to serve as a link sector, and the next one sector is 
caused to serve as sub data sector. To this sub data sec- 
tor, sub data except for audio data is allocated. The link 
sector is caused to serve as an area for connecting clus- 
ters before and after, and audio data is recorded only in 
32 sectors except for the link sector and the sub data 
sector. 

[0005] On the other hand, in mini-disks dedicated to 
reproduction, data are continuously recorded (are not 
discretely recorded), and three sectors of the link area 
therefore become unnecessary. Accordingly, in this 
case, these three sectors are caused to also serve as 
sub data sector. 

[0006] One sector consists of 2352 bytes (2332 bytes 
for data), and 11 sound groups are allocated to two suc- 
cessive sectors. One sound group consists of 424 bytes, 
and audio data of the left channel and the right channel 
are allocated thereto by 51 2 samples (11 .61 ms) in total. 
Recording of digital audio data is carried out with the 
sound group being as unit. 

[0007] It is conceivable to use such mini-disc as, e.g., 
storage unit of computer. In this case, in order to carry 
out management of data of computer as file, since clus- 
ter (36 sectors) is too large as unit, it is preferable to 
have ability of recording data in a unit (e.g., sector unit) 
smaller than cluster. However, as described above, 



since it is prescribed by the standardization require- 
ments that mini-disc must record data thereonto with 
one cluster being as unit, there is the problem that it is 
unable to record data in a unit smaller than one cluster 
5 (e.g., sector unit). 

[0008] Further, for example, in the case of recording 
both data of computer and audio data onto a mini-disc, 
it is conceivable to partition in advance the area for re- 
cording data similarly to recording in hard disc. 
[0009] In the case where 2200 clusters from cluster 0 
up to cluster 21 99 exist on a mini-disc, as shown in FIG. 
30, for example, the recording area is partitioned into 
area (A) from cluster 0 up to cluster 650, area (B) from 
cluster 651 up to cluster 1100, and area (C) from cluster 
1101 up to cluster 2199, thus making it possible to 
record audio data into, e.g., partitions A and C of respec- 
tive areas (partitions), and to record data of computer 
into partition B thereof. 

[0010] However, in the case where the recording area 
is partitioned in advance in correspondence with kind of 
data in this way, when, e.g., data of computer to be re- 
corded is above capacity of partition B, even if empty 
areas exist in the partition A and the partition C, data of 
computer is disadvantageously no longer recorded onto 
that mini-disc. In contrast, when partition A and partition 
C are filled with data, even if any empty area exists in 
the partition B, it is impossible to record audio data be- 
yond that. 

[0011] Further, management method of dividing the 
recording area into partitions in this way is management 
method basically different from the management meth- 
od having cluster as unit. 

For example, when a mini-disc having a recording area 
divided into a plurality of partitions in which data of com- 
puter is recorded in a predetermined partition and audio 
data is recorded in any other partition is reproduced by 
an apparatus dedicated for reproducing audio data, 
there is the possibility that the audio data may not be 
reproduced. 

Namely, it becomes difficult to guarantee compatibility. 
Thus it is an object of the present invention to broaden 
the usability of such recording media, i.e. to make it pos- 
sible to record data in a data recording unit which may 
be smaller than a standarized one for recording data. 
This object is solved according to the method of claim 1 . 
Further advantageous features are set forth in the de- 
pendent claims. 

Further the invention provides for a system and record- 
ing medium using the recording medium management 
method of this invention. 

Further, in accordance with this invention, in the case 
where an empty area exists, it is possible to record both 
computer data and audio data at all times as occasion 
demands. 

In addition, this invention makes it possible to ensure 
compatibility with ordinary mini-disc. 
In the recording medium management method thus fea- 
tured, a predetermined range or area is designated from 
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FIG. 19 is a view for explaining format of extent 
record block entry of FIG. 13. 
FIG. 20 is a view showing an example of the con- 
figuration of extent record block of FIG. 13. 
5 FIG. 21 is a view for explaining format of extent 
record index. 

FIG. 22 is a view for explaining format of extent de- 
scriptor. 

FIG. 23 is a view for explaining the relationship be- 
10 tween index and extent record. 

FIG. 24 is a view showing another example of the 
configuration of U-TOC. 

FIG. 25 is a view for explaining the configuration of 
bitmap. 

15 FIG. 26 is a flowchart for explaining another opera- 
tion for initializing mini-disc 1. 
FIG. 27 is a flowchart for explaining another opera- 
tion in the case of recording computer data onto 
mini-disc 1. 

20 FIG. 28 is a view for explaining bitmap in the state 
where computer data is recorded. 
FIG. 29 is a view for explaining format of mini-disc. 
FIG. 30 is a view for explaining concept of partition. 

25 Best Mode for Carrying Out the Invention 
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the area caused to undergo management by the first or 
management table of U-TOC, and the designated area 
is caused to undergo management by the second table 
or FAT or bitmap. Accordingly, it is possible to record 
computer data in the designated area with a second da- 
ta recording unit or sector smaller than a first data re- 
cording unit or cluster. Further, such designation is sup- 
plemented as occasion demands, thereby making it 
possible to supplementarily record not only digital audio 
data but also computer data as long as any empty area 
exists. In addition, compatibility with mini-discs on which 
only ordinary data are recorded is ensured. 

Brief Description of the Drawings 

[0012] 

FIG. 1 is a view showing the configuration of ap- 
pearance of a mini-disc device to which a recording 
medium management method of this invention is 
applied. 

FIG. 2 is a block diagram showing internal configu- 
ration of body 41 of the embodiment of FIG. 1 . 
FIG. 3 is a view for explaining format of U-TOC of 
mini-disc 1 of FIG. 2. 
FIG. 4 is a view for explaining link of management 
table of FIG. 3. 

FIG. 5 is a view for explaining the relationship be- 
tween management table and data recording area. 
FIG. 6 is a view for explaining the relationship be- 
tween management table and data recording area 
when the area for recording computer data is en- 
sured. 

FIG. 7 is a view for explaining FAT. 
FIG. 8 is a view for explaining FAT in the state where 
computer data is recorded. 
FIG. 9 is a flowchart for explaining the operation for 
initializing mini-disc 1 in the embodiment of FIG. 2. 
FIG. 10 is a view for explaining the operation in the 
case where computer data is recorded onto mini- 
disc 1 in the embodiment of FIG. 2. 
FIG. 11 is a view for explaining format of mini-disc 
1 in another embodiment of the recording medium 
management method of this invention. 
FIG. 1 2 is a view for explaining format of data track 
of FIG. 11. 

FIG. 13 is a view for explaining format of volume 
management area of FIG. 12. 
FIG. 14 is a view for explaining format of manage- 
ment table of FIG. 13. 

FIG. 15 is a view for explaining format of directory 

record block entry of FIG. 13. 

FIG. 16 is a view for explaining format of directory 

record block entry of FIG. 13. 

FIG. 17 is a view for explaining format of directory 

record block entry of FIG. 13. 

FIG. 18 is a view for explaining format of directory 

record block entry of FIG. 13. 



[0013] FIG. 1 shows the configuration of appearance 
of an embodiment of a mini-disc device to which a re- 
cording medium management method of this invention 
is applied. Within disc cartridge 1a, a mini-disc 1 (FIG. 
2) is accommodated. This cartridge 1a is adapted so 
that it can be loaded into body 41 from opening for in- 
sertion designated at 42. At the bottom portion on the 
right side of body 41 , an operation input section 1 9 in- 
cluding power switch 19 in the form of push-button and 
eject push-button 19b, etc. is provided. The power 
switch 1 9a is operated when the power supply is turned 
ON or OFF, and the eject push-button 19b is operated 
when cartridge 1a is ejected. Further, display section 18 
is disposed at the central portion on the upper surface 
of body 41 . The body 41 is connected to host CPU 31 
(FIG. 2) through SCSI bus 30. 

[0014] FIG. 2 shows the internal configuration of body 
41. In this figure, mini-disc (magneto-optical disc) 1 on 
which, e.g., both a plurality of musical pieces (audio da- 
ta) and computer data, or only computer data are or is 
recorded is rotationally driven by spindle motor 2. Opti- 
cal head 3 irradiates laser beams to mini-disc 1 at the 
time of recording/reproduction. Namely, at the time of 
recording, laser beams of high level for heating record- 
ing tracks to Curie temperature are outputted. On the 
other hand, at the time of reproduction, laser beams of 
a relatively lower level for detecting data from a reflected 
light by the magnetic kerr effect are outputted. 
[0015] For this reason, optical head 3 includes a laser 
diode for outputting laser beams, an optical system 
composed of a polarizing beam splitter, object lens (ob- 
jective) and the like, and a detector for detecting a re- 
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fleeted light. Among these components, object lens 3a 
is held so that it can undergo displacement in a disc ra- 
dial direction (tracking direction) and a direction in which 
it is in contact with the disc or is away therefrom (focus 
direction) by biaxial mechanism 4, and the entirety of 
optical head 3 can be moved in a disc radial direction 
by sled mechanism 5. 

[001 6] Further, magnetic head 6 is disposed at the po- 
sition opposite to optical head 3 with mini-disc 1 being 
put between magnetic head 6 and optical head 3 so as 
to apply, to mini-disc 1 , magnetic field modulated by data 
delivered to the magnetic head 6. 
[0017] By the reproducing operation, information de- 
tected from mini-disc 1 by optical head 3 is delivered to 
RF amplifier 7. The RF amplifier 7 extracts, by operation 
processing of information delivered thereto, reproduc- 
tion RF signal, tracking error signal, focus error signal, 
ATIP information (absolute time information recorded as 
pregroove (wobbling groove) on mini-disc 1), address 
information, sub code information, and focus monitor 
signal, etc. 

[0018] The extracted reproduction RF signal is deliv- 
ered to encoder/decoder section 8. Moreover, tracking 
error signal and focus error signal are delivered to servo 
circuit 9, and address information is delivered to address 
decoder 1 0. Further, ATIP information and focus monitor 
signal are delivered to system controller 11 comprised 
of, e.g., microcomputer (CPU). 
[0019] The servo circuit 9 generates various servo 
drive signals by tracking error signal and focus error sig- 
nal delivered from RF amplifier 7, and track jump com- 
mand, seek command and rotational speed detection 
information, etc. from system controller 11 to control bi- 
axial mechanism 4 and sled mechanism 5 to allow them 
to carry out focus and tracking controls, and to control 
spindle motor 2 so that it is driven at a constant angular 
velocity (CAV) or at a constant linear velocity (CLV). 
[0020] Reproduction RF signal is EFM-demodulated 
at encoder/decoder section 8. The signal thus modulat- 
ed is caused to undergo decode processing such as 
CIRC, etc., and is then once written into buffer RAM 13 
by memory controller 12. In this case, reading of data 
from mini-disc 1 by optical head 3 and transfer of repro- 
duction data from optical head 3 up to buffer RAM 13 
are carried out at a transfer rate of 1 .41 M bits/sec. 
[0021] Data written into buffer RAM 13 is delivered to 
host CPU 31 through SCSI interface 14. 
[0022] Address information outputted from address 
decoder 10 is delivered to system controller 11 through 
encoder/decoder section 8, at which it is used for vari- 
ous control operations. 

[0023] Further, lock detection signal of PLL circuit for 
generating bit clock of recording/reproducing operation 
and signal for monitoring missing state of frame syn- 
chronizing signal of reproduction data are also delivered 
to system controller 11. 

[0024] When recording operation is executed with re- 
spect to mini-disc 1 , recording data is delivered to mem- 



ory controller 1 2 through SCSI interface 14 by host CPU 
31 . This recording data is once written into buffer RAM 
13 by memory controller 12, and is read out therefrom 
at a predetermined timing. The signal thus read out is 
5 sent to encoder/decoder section 8. At the encoder/de- 
coder section 8, predetermined processing such as 
CIRC encode, EFM modulation, etc. are implemented 
thereto. The signal thus processed is delivered to mag- 
netic head drive circuit 15. 

[0025] The magnetic head drive circuit 15 delivers 
magnetic head drive signal to magnetic head 6 in de- 
pendency upon the recording data which has under- 
gone encode and modulation processing, etc. Namely, 
mini-disc 1 is caused to execute application of magnetic 
field of N or S by magnetic head 6 with respect to mini- 
disc 1 . At this time, system controller 1 1 delivers, to op- 
tical head 3, a control signal so as to output laser beams 
of recording level. 

[0026] For example, on display section 18 comprised 
of liquid crystal display, a predetermined character, etc. 
is displayed in correspondence with command from sys- 
tem controller 11. The operation input section 19 in- 
cludes reproduction key, stop key, AMS key and search 
key, etc. in addition to the above-described power switch 
19a, eject push-button 19b, and inputs a signal corre- 
sponding to that operation to system controller 11. 
[0027] RAM (hereinafter referred to as TOC memory) 
16 holds TOC information in mini-disc 1. At the time 
point when mini-disc 1 is loaded, or immediately before 
recording or reproducing operation, system controller 1 1 
drives spindle motor 2 and optical head 3 to extract data 
in TOC area set, e.g., on the innermost circumferential 
side of mini-disc 1 . Then, TOC information delivered to 
system controller 11 through RF amplifier 7 and encod- 
er/decoder section 8 is stored into TOC memory 16. Af- 
ter that, such information is used for control of recording/ 
reproducing operation with respect to that mini-disc 1. 
Memory 17 stores FAT (File Allocation Table) informa- 
tion or bitmap which will be described later. 
[0028] Host CPU 31 not only carries out control of 
transmission/reception of computer data, but also con- 
trol transmission/reception of FAT information or bitmap, 
or updating of FAT information or bitmap. It is to be noted 
that memory 17 may be provided on the body 41 side. 
[0029] On writable mini-disc 1 , segment management 
data for permitting a series of musical pieces to be dis- 
cretely (or continuously) recorded/reproduced as one 
segment (parts) or plural divided segments (parts) is fur- 
ther recorded. Namely, for management of recording 
data area user TOC (hereinafter referred to as U-TOC) 
such that the content is rewritten in accordance with re- 
cording or erasing of data is recorded in the form of data 
structure as shown in FIG. 3, for example. 
[0030] This U-TOC is recorded in the area of, e.g., 4 
bytes x 587 within data area. In that area, header having 
synchronization patterns each comprised of 1 byte data 
of which respective bits are all 0 or all 1 are provided at 
the leading position in order that this area indicates 
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U-TOC area. 

[0031] Moreover, at predetermined address posi- 
tions, data such as music number of the first musical 
piece (First TNO) and music number of the last musical 
piece (Last TNO), the use state of sector, and disc ID, 
etc. which are recorded on this mini-disc 1 are recorded. 
Further, there are prepared areas for recording various 
correspondence table indication data (P-DFA ~ 
P-TN0255) which allow respective musical pieces, etc. 
recorded to correspond to management table which will 
be described later. 

[0032] On the other hand, 255 parts tables having 
numbers (01 h) ~ (FFh) are provided as management 
table. In each parts table, there can be recorded start 
address serving as starting point with respect to a cer- 
tain segment, end address serving as terminating point 
thereof, mode information of that segment (track), and 
link information in which when that segment is continu- 
ously connected to any other segment, it indicates parts 
table where start address and end address of the seg- 
ment to be connected are recorded. 
[0033] More particularly, mode information of track is 
information indicating whether or not that track is set to, 
e.g., overwrite protection or data copy protection, infor- 
mation indicating kind of audio information or computer 
information, etc., information indicating kind of monau- 
ral/stereo, and the like. Link information designates a 
parts table to be connected by, e.g., numbers (01 h) ~ 
(FFh) given to respective parts tables. 
[0034] Namely, in the management table, one parts 
table represents one segment. For example, with re- 
spect to the musical piece where three segments are 
connected, management of that segment position is car- 
ried out by three parts tables connected by link informa- 
tion. It is to be noted that, for the above reason, numbers 
(01 h) ~ (FFh) of parts tables can be segment (parts) 
numbers as they are. 

[0035] In respective parts tables of (01 h) ~ (FFh) in 
the management table, the content of that segment is 
indicated by correspondence table indication data 
(P-DFA - P-TN0255). 

[0036] P-DFA indicates defective area on mini-disc 1 , 
i.e., designates one parts table or the leading parts table 
within plural parts tables where track portion (=segment) 
serving as defective area due to flaw is indicated. Name- 
ly, in the case where any defective segment exists, any 
one of (01 h) ~ (FFh) is recorded into the area of corre- 
spondence table indication data P-DFA, and defective 
segment is indicated by start and end addresses in parts 
table corresponding thereto. Moreover, in the case 
where any other defective segment exists, correspond- 
ing other parts table is designated as link information in 
that parts table, and defective segment is indicated also 
in that parts table. Further, in the case where that seg- 
ment is the last defective segment, link information is 
caused to be, e.g., (OOh), and it is indicated that no seg- 
ment is linked in areas succeeding thereto. 
[0037] P-EMPTY indicates one unused parts table or 



the leading parts table of plural parts tables in the man- 
agement table. In the case where any unused parts ta- 
ble exists, any one of (01 h) ~ (FFh) is recorded as cor- 
respondence table indication data P-EMPTY. In the 
5 case where a plurality of unused parts tables exist, parts 
tables are sequentially designated by link information 
from part table designated by correspondence table in- 
dication data P-EMPTY. Thus, all unused parts table are 
connected (linked) on the management table. For ex- 
ample, in the case of the magneto-optical disc on which 
no data is recorded and there is no defective, all parts 
tables are not used. For this reason, connection to parts 
table (FFh) is carried out such that, e.g., parts table 
(01 h) is designated by correspondence table indication 
data P-EMPTY, parts table (02h) is designated as link 
information of parts table (01 h), and parts table (03h) is 
designated as link information of parts table (02h). In 
this case, link information of parts table (FFh) is caused 
to be (OOh) indicating that there is no connection at areas 
succeeding thereto. 

[0038] P-FRA indicates a unrecorded area (including 
erase area) of data on mini-disc 1 , and designates one 
parts table or the leading parts table within plural parts 
tables where track portion (segment) serving as unre- 
corded area is indicated. Namely, in the case where any 
unrecorded area exists, any one of (01 h) ~ (FFh) is re- 
corded in the area of correspondence table indication 
data P-FRA. In a parts table corresponding thereto, seg- 
ment serving as a unrecorded area is indicated by start 
address and end address. In addition, in the case where 
there are a plurality of segments described above, i.e., 
there are a plurality of parts tables, designation up to 
the parts table where link information is caused to be 
(OOh) by is sequentially carried out link information. 
[0039] Management state by parts table of segment 
serving as unrecorded area is shown in a model form in 
FIG. 4. Namely, FIG. 4 shows the state where when seg- 
ments where start addresses and end addresses are re- 
spectively indicated by (S 03h , E 03h ), (S 18h> E 18h ), (S 1Fh , 
E iFh)» ( S 2Bh» E 2Bh)» ( S E3h» E E3h) are caused to be unre- 
corded area, such segment unrecorded area arrange- 
ment state is represented, subsequently to correspond- 
ence table indication data P-FRA, by link of parts tables 
(03h), (18h), (1Fh), (2Bh), (E3h). It is to be noted that 
management mode of defective area and/or unused 
parts table described above are the same as the state 
shown in FIG. 4. 

[0040] P-TN01 ~ P-TN0255 indicate areas with re- 
spect to respective musical pieces (tracks) recorded on 
mini-disc 1 . For example, correspondence table indica- 
tion data P-TN01 designates parts table in which one 
segment or the leading segment in point of time of plural 
segments where data of the first musical piece is record- 
ed. 

[0041] In the case where, for example, musical piece 
which has been selected as the first musical piece is 
recorded without being divided (i.e., by one segment) 
on disc, recording area of the first musical piece is re- 
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corded as start and end addresses in the parts table in- 
dicated by correspondence table indication data 
P-TN01. 

[0042] Moreover, in the case where, e.g., musical 
piece which has been selected as the second musical 
piece is recorded discretely in a plurality of segments 
on disc, respective segments are designated (linked) in 
accordance with order in point of time for the purpose 
of indicating the position of that musical piece. Namely, 
other parts tables are further sequentially designated in 
accordance with order in point of time by link information 
from parts table designated by correspondence table in- 
dication data P-TN02, and connection up to parts table 
where link information is caused to be (OOh) is carried 
out (the same mode as that of FIG. 4). 
[0043] As stated above, all segments where data con- 
stituting, e.g., the second musical piece are sequentially 
designated and stored, whereby in carrying out repro- 
duction of the second musical piece or overwrite into the 
area of the second musical piece by using this U-TOC 
data, optical head 3 and magnetic head 6 are caused to 
be accessed, thereby making it possible to take out con- 
tinuous music information from discrete segments, or to 
carry out recording efficiently using the recording area. 
[0044] As stated above, U-TOC data recorded on 
mini-disc 1 is read out and is stored into TOC memory 
1 6. U-TOC data which has been read into TOC memory 
16 is used to carry out management of the recording 
area on disc, thus making it possible to control the re- 
cording/reproducing operation. 
[0045] The above-mentioned U-TOC data is also re- 
corded similarly as in the case of mini-disc, on which 
ordinary musical pieces are recorded. In the mini-disc 
of this embodiment, in order to have ability of recording, 
e.g., computer data except for audio data (musical 
piece), LOFAT (Location of FAT) is recorded as data of 
16 bits. This LOFAT will be described later. 
[0046] FIG. 5 shows, in a model form, the relationship 
between management table (parts table) of U-TOC and 
cluster of data recording area of mini-disc 1. This exam- 
ple indicates unrecorded area of data on mini-disc 1. 
Parts table No. indicating the leading cluster of the un- 
recorded area is prescribed as (01 h) in correspondence 
table indication data P-FRA. Namely, position of the 
leading segment as unrecorded area of data is de- 
scribed in parts table (01 h). 

[0047] When reference is made to parts table of this 
number (01 h), its start address is caused to be cluster 
9, and end address is caused to be cluster 1 2. From this 
fact, it is seen that cluster 9 to cluster 12 of the data 
recording area are caused to be continuously unrecord- 
ed area. (OAh) is described as link information in the 
parts table of this number (01 h). This indicates that data 
relating to segments of unrecorded areas subsequent 
to class 9 to cluster 12 is described in the parts table of 
number (OAh). 

[0048] When attention is drawn to the parts table of 
number (oAh), its start address is caused to be cluster 



29, and its end address is caused to be cluster 30. 
Namely, it is seen that segment from cluster 29 to cluster 
30 exists as unrecorded area in the data recording area. 
[0049] Moreover, (04h) is described as link informa- 
5 tion of this number (OAh). When attention is drawn to 
parts table of the number of (04h), its start address is 
caused to be cluster 104 and its end address is caused 
to be cluster 105. Namely, it is seen that unrecorded ar- 
ea consisting of clusters 104 and 105 exists as the third 
segment subsequent to cluster 29 and cluster 30. 
[0050] Further, link information of (07h) is described 
in the parts table of (04h). When attention is drawn to 
parts table of (07h), its start address is caused to be 
cluster 82 and its end address is caused to be cluster 
87. Namely, the forth segment from cluster 82 to cluster 
87 is caused to be unrecorded area. Since (OOh) is de- 
scribed in link information of this parts table of (07h), it 
is seen that the fourth segment is the last segment of 
the unrecorded area. 

[0051] As described above, digital audio data is basi- 
cally recorded in respective clusters of the data record- 
ing area. However, in the case of recording computer 
data into a predetermined range (cluster) in place of dig- 
ital audio data, the range for recording computer data is 
first designated with cluster being as unit by host 
CPU31 , as shown in FIG. 6, for example. 
[0052] In the example of FIG. 6, segment consisting 
of 12 clusters from cluster 1 6 to cluster 27 is designated 
as segment for recording computer data. Since this seg- 
ment is the fifth segment, (02h) is described as number 
of parts table relating to the leading segment for record- 
ing computer data in the correspondence table indica- 
tion data P-TN05 of the above-described U-TOC. When 
attention is drawn to the parts table of (02h), cluster 16 
is described as start address, and cluster 27 is de- 
scribed as end address. Since (OOh) is described as link 
information, it is seen that only one segment consisting 
of 12 clusters from cluster 16 to cluster 27 is prepared 
as segment for recording computer data. 
[0053] When the area for recording computer data is 
designated in the management table (parts table) in this 
way, FAT as table for carrying out management of file 
for recording computer data as shown in FIG. 7 is 
formed at a predetermined track of the data recording 
area on mini-disc 1. As shown in FIG. 6, for example, 
FAT is recorded into the leading cluster 16 of the area 
for recording computer data of cluster 16 to cluster 27 
(It is of course that FAT may be recorded into, e.g., 
U-TOC area). At this time, (02h) is described at LOFAT 
in order that recording position of FAT can be seen. 
[0054] One block of FAT consists of 2 bytes. Respec- 
tive blocks correspond to the area of predetermined size 
(e.g., cluster) of the data recording area. Namely, in the 
example shown in FIG. 6, since segment from clusters 
1 6 to 27 in the data recording area is designated as com- 
puter data recording area, (FFEh) indicating available 
unused block is described in blocks 17 to 27 corre- 
sponding to these clusters 1 6 to 27. It is to be noted that 
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when FAT is recorded in cluster 16, (FFDh) is recorded 
in block 16 of FAT corresponding to this cluster. This in- 
dicates that data is recorded at that portion (correspond- 
ing cluster 16), and that data terminates at that portion 
(corresponding cluster 16). 

[0055] Since respective clusters except for clusters 
16 to 27 of the data recording area are not designated 
as the area for recording computer data, in other words, 
it is inhibited to use such cluster area as the area for 
recording computer data, data (FFFh) indicating disa- 
bled block is described. 

[0056] FIG. 8 shows FAT in the state where computer 
data is recorded in a predetermined range of clusters 
16 to 27 thus ensured. In this example, No. of block 18 
is described in block 1 7 corresponding to cluster 1 7, No. 
of block 19 is described in block 18, No. of block 20 is 
described in block 19, and data (FFDh) indicating the 
last block of segment is described in block 20. Accord- 
ingly, it is seen that a series of computer data are re- 
corded in the segment consisting of four clusters from 
cluster 17 to cluster 20. 

[0057] Further, block No. 22 is described in block 21 , 
block No. 23 is described in block 22, block No. 24 is 
described in block 23, block No. 25 is described in block 
24, and (FFDh) is described in block 25. Namely, a se- 
ries of computer data are recorded in five clusters from 
cluster 21 to cluster 25. 

[0058] It is to be noted that since data of blocks 26 
and 27 remain to be (FFEh), clusters 26 and 27 remains 
to be unused area where computer data is not yet re- 
corded. 

[0059] FIG. 9 shows an example of processing carried 
out by host CPU 31 when mini-disc 1 (cartridge 1a) is 
loaded into body 41 of mini-disc device for carrying out 
recording/reproduction of computer data to instruct ini- 
tialization. Initially, at step S1 , whether or not No. indi- 
cating parts table on a predetermined management ta- 
ble is described in LOFAT of U-TOC of mini-disc 1 is 
judged. In the case where No. of a predetermined pats 
table is described in LOFAT, since initialization for re- 
cording computer data has been already completed (re- 
cording area is ensured), initialization processing is 
completed. 

[0060] At step S1 , in the case where it is judged that 
a predetermined number is not described in LOFAT, the 
processing proceeds to step S2. Thus, empty area 
(empty parts table) is ensured from U-TOC (data track 
is ensured). As shown in FIG. 6, for example, predeter- 
mined 12 clusters (12 clusters from cluster 16 to cluster 
27 in FIG. 6) are ensured as computer data recording 
track from empty areas in the data recording area 
(whether or not a corresponding area is an empty area 
can be recognized from P-TN01 ~ P-TNO 255 of 
U-TOC). Then, this segment is registered into P-TN05, 
and its start address and its end address are registered 
into pars table (02h). 

[0061] Then, the processing proceeds to step S3. At 
this step, FAT as shown in FIG. 7 is written into an arbi- 



trary cluster (e.g., the leading cluster 1 6) of (12 clusters) 
within the area of data track ensured at step S2. In FAT, 
data (FFDh) indicating used block and having no block 
to be linked is recorded into block 16 corresponding to 
5 cluster 16 into which FAT is written. Moreover, data 
(FFEh) is recorded as available unused block into 
blocks 17 to 27 of FAT corresponding to clusters 17 to 
27 where no FAT is recorded. In addition, data (FFFh) 
is recorded as disabled block into blocks of FAT corre- 
sponding to clusters except for the above. 
[0062] Then, the processing proceeds to step S4. At 
this step, No. of parts table corresponding to cluster 
where FAT is recorded is described in LOFAT of U-TOC. 
[0063] It is to be noted that FAT data is temporarily 
stored into memory 1 7, and is recorded into FAT on mini- 
disc 1 at a predetermined timing. 
[0064] FIG. 10 shows an example of processing exe- 
cuted by host CPU 31 in the case where computer data 
is recorded onto mini-disc 1. Initially, at step S11, host 
CPU 31 reads in FAT that LOFAT of U-TOC indicates 
(FAT of cluster 16 of the data recording area of FIG. 6) 
recorded on mini-disc 1 . This data is temporarily stored 
into memory 1 7, and CPU 31 reads in this data at a pre- 
determined timing. 

[0065] Then, the processing proceeds to step S12. At 
this step, whether or not there is available unused block 
in the entry of FAT which has been currently read in is 
judged. In the case of initially recording computer data, 
since available unused block exists, the processing pro- 
ceeds from step S12 to step S15. At the step S15, one 
block (e.g., block 17 of FAT of FIG. 8) is selected from 
unused blocks. The block thus selected is caused to cor- 
respond to file into which data is to be written. Then, 
data is actually written into cluster to which that block 
corresponds (e.g., cluster 17 of the data recording area 
of FIG. 6). 

[0066] Then, the processing proceeds to step S1 6. At 
this step, whether or not block allocated to correspond- 
ing file exists before the block currently allocated is 
judged. In the case of initial recording, since block allo- 
cated earlier does not exist, the processing proceeds 
from step S16 to step S18. At the step S18, whether or 
not writing of all data has been completed is judged. As 
a result, if such writing operation is not completed, the 
processing returns to step S12. 
[0067] Such an operation is repeated. At the second 
processing and processing subsequent thereto, it is 
judged at step S16 that block earlier allocated to the file 
exists. For this reason, in this case, the processing pro- 
ceeds from step S1 6 to step S1 7 to register current block 
No. into entry of FAT of the former block. Namely, as 
explained with reference to FIG. 8, current block No. 18 
is registered into, e.g., block 17. Similarly, block No. 19 
is recorded into block 18 and block No. 20 is recorded 
into block 19. 

[0068] In the case where the ensured area is filled as 
the result of repetition of the above-mentioned operation 
and it is judged at step S1 2 that available unused block 
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dose not exist in entry of FAT, i.e., when there is no emp- 
ty area for recording computer data, the processing pro- 
ceeds to step S13 to ensure an empty area of U-TOC 
to supplement that empty area as data track for record- 
ing computer data. Then, the processing proceeds to 
step S14 to register, as available unused block, block of 
area supplemented as data track into entry of FAT. 
Namely, processing similar to steps S2, S3 in the initial- 
ization processing of FIG. 9 is carried out to newly en- 
sure (supplement) data recording area of 12 clusters. It 
is to be noted that since FAT has been already prepared, 
only data corresponding thereto is updated without new- 
ly preparing FAT. 

[0069] By carrying out processing of these steps S1 3, 
S14, empty area on mini-disc 1 is supplemented upon 
occasion as data track for recording computer data. Ac- 
cordingly, occurrence of an unfavorable phenomenon 
such that it becomes unable to record computer data 
although any empty area exists on the disc as in the 
case where a predetermined range is partitioned in ad- 
vance as partition can be prevented. 
[0070] In the case where it is judged at step S18 that 
writing of all data has been completed, the processing 
proceeds to step S19 to register FAT entry of current 
block as the last block to update FAT. Namely, as in the 
case of block 20 of FAT of FIG. 8, data (FFDh) is record- 
ed into the block. 

[0071] It is to be noted that while numbers (01 h) ~ 
(FFh) of parts table are described in LOFAT, since 16 
bits are ensured for LOFAT, address in the data record- 
ing area may be directly recorded. 
[0072] Assuming now that when the number of clus- 
ters of the entirety of the area of mini-disc 1 is 2200 and 
capacity of one cluster is 64 k bytes, capacity of the en- 
tirety of mini-disc 1 becomes equal to 140 M bytes (= 
2200 x 64 k bytes). 

[0073] If the range of 8 k bytes of recording data area 
is caused to correspond to one block of FAT, 17,600 (= 
140M bytes/8 k bytes) blocks are required as the 
number of blocks (the number of entries) of FAT. When 
one entry (block) is formed by 2 bytes (16 bits), about 
35 k bytes (=17,600 x 2 bytes) is required as capacity 
of FAT. Eventually, when 8 k bytes (the range which is 
one eighth of 64 k bytes which is one cluster) in the data 
recording area are caused to correspond to one block 
of FAT, FAT having capacity of 35 k bytes is required in 
order to carry out management of the range of the en- 
tirety of one disc. 

[0074] A quantity of allocation of one block of FAT 
serves as unit of data recording. As described above, if 
this quantity of allocation is 64 k bytes (1 cluster), writing 
similar to that of the ordinary mini-disc can be carried 
out. However, when an attempt is made to sufficiently 
transfer computer data, it is preferable that the quantity 
of allocation is about 8 k bytes smaller than 64 k bytes. 
In addition, when such a scheme is employed, recording 
of data can be made in a unit smaller than cluster. 
[0075] It is to be noted that in the case of recording 



data in unit of 8 k bytes, data of one cluster including 
block of 8 k bytes is once read out from mini-disc 1 , and 
is stored into RAM 13. Then, data corresponding to 8 k 
bytes of data of one cluster stored in RAM 13 is newly 
5 stored. Data of 1 cluster is written onto mini-disc 1. 
Namely, recording of only data of substantially 8 k bytes 
is carried out. Further, at the time of reproduction, host 
CPU 31 reads data in one sector unit. 
[0076] In the case where a mini-disc recorded so that 
computer data (of course, other data may be employed) 
exists mixedly with audio data is loaded on a mini-disc 
device for ordinary musical pieces, computer data can- 
not be reproduced, but audio data can be reproduced. 
If there is any empty area, it is possible to supplemen- 
tary record audio data. 

[0077] While management of data track is carried out 
by using FAT in the above-described embodiment, an 
embodiment in which management of data track is car- 
ried out by using no FAT will now be described. 
[0078] FIG. 11 shows a recording format of writable 
mini-disc 1 in the case where this embodiment is real- 
ized. As shown in this figure, on the innermost circum- 
ferential side and the outermost circumferential side 
from the innermost circumference (left side in the figure) 
to the outermost circumference (right side in the figure), 
Lead-in area and Lead-out area are respectively provid- 
ed. TOC (Table of Contents) data, etc. is recorded as 
occasion demands into the Lead-in area and the Lead- 
out area. General user cannot record information into 
these areas. 

[0079] The area except for Lead-in area and Lead-out 
area of information area is caused to be recordable ar- 
ea, and general user can record data into the recordable 
area or reproduce it therefrom. On the innermost cir- 
cumferential side of the recordable area, UTOC (User 
TOC) area is provided. Outside that area, program area 
is provided. Into the UTOC area, the above-mentioned 
U-TOC data is recorded. In the program area, audio da- 
ta, data processed in computer, or other data can be 
recorded. 

[0080] In the program area, respective data are dis- 
cretely recorded. In the example of FIG. 11, audio data 
is recorded on track Trk1 . Namely, this track is caused 
to be audio track. This track Trk1 consists of two parts 
(Trk1-1, Trk1-2). Parts (tracks) Trk1-1 and Trk1-2 are 
formed at the position away from each other on the disc. 
For example, when that data is reproduced, optical head 
3 seeks parts Trk1-2 when reproduction of parts Trk1-1 
is completed to reproduce it. For this reason, reproduc- 
tion data can be continuously obtained. 
[0081] In this example, in addition to the above-men- 
tioned feature, audio tracks Trk2-1 and Trk4-1 are re- 
spectively comprised of one parts, and audio data are 
recorded thereinto. 

[0082] Further, in this embodiment, track Trk3 con- 
sisting of parts Trk3-1 to 3-3 is formed, and data proc- 
essed by host CPU 31 is recorded thereonto. 
[0083] EFM ■ CIRC encoder/decoder 8 carries out 
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processing so that data is recorded and reproduced with 
cluster (64 k bytes) being as unit with respect to respec- 
tive tracks of the program area. 
[0084] Data track consists of Volume Management 
Area and Extent Area. Volume Management Area is 
formed at the leading portion of data track initially 
formed in the program area. Extent Area is caused to 
be an area except for the above. 
[0085] Individual managements of Allocation Block of 
Volume Management Area and Extent Area are carried 
out. The former is caused to have 2 k bytes, and the 
latter is caused to have any one (e.g., 8 k bytes) of 4 k 
bytes, 8 k bytes, 16 k bytes, 32 k bytes and 64 k bytes. 
[0086] Volume Management Area consists of 1 6 clus- 
ters as shown in FIG. 12. Before one cluster of Volume 
Management Area, Boot Cluster is allocated as occa- 
sion demands. 

[0087] FIG. 13 shows a format of the Volume Man- 
agement Area. This Volume Management Area consists 
of 1 6 clusters and one cluster consists of 64 k bytes. For 
this reason, 1024 blocks of 2 k bytes are formed in the 
Volume Management Area. 

[0088] In the first block of number 0, VD (Volume De- 
scriptor) is recorded. In this Volume Descriptor, e.g., 
number of blocks where root directory is recorded (any 
one of 0 to 1023 (4 in the case of this example)) and/or 
position information of volume space bit map, etc. are 
recorded. 

[0089] In the block of No. 1, Volume Space Bitmap 
(VSB) is allocated. In the VSB, bitmap indicating the use 
state of the entirety of mini-disc 1 is recorded. This bit- 
map will be described later. 

[0090] Management Table (MT) is allocated to the 
block of 4 bytes in total of No. 2 and No. 3. Use state of 
the Volume Management Area is recorded in MT. 
[0091] FIG. 14 shows, in a model form, Management 
Table consisting of two blocks of No. 2 and No. 3. As 
shown in the figure, respective blocks having capacity 
(volume) of 4 bytes indicated by numbers 0 to 1023 cor- 
respond to block of 2k bytes indicated by numbers of 
blocks of 0 to 1023 in FIG. 13. In FIG. 13, since blocks 
of numbers 0 to 3 are prescribed in advance by stand- 
ardization requirement, data is not particularly recorded 
(is caused to be reserved) in the corresponding area 
(block) on the Management Table of FIG. 14. 
[0092] As shown in FIG. 1 3, Directory Records Blocks 
(DRB) or Extent Records Blocks (ERB) are allocated to 
the No. 4 block and blocks succeeding thereto. 
[0093] In the Directory Records Block DRB, the fol- 
lowing information (directory management information 
and file management information) are recorded: 

Directory (Name, Index to DRB, ID, Size, Date, etc.) 
File (Name, Index to ER (Index to ERB, Offset of 
ER), Extent start Location, Number of Blocks, ID, 
Size, Date, etc.) 

Directory Records Block Entry of Management Ta- 
ble for recording data of the Directory Records 



Block DRB is constructed as shown in FIG. 15 or 
FIGS. 16 to 18. 

[0094] The format shown in FIG. 15 indicates format 
5 in the case where Directory Records Block Entry con- 
sists of only one DRB. In this case, O is set to the first 
bit 31 of data of 4 bytes, and ID is recorded in the re- 
maining 31 bits from bit 30 to bit 0. For example, Direc- 
tory Record Block Entry corresponding to block of 
number 4 of FIG. 14 is constituted with this format. In 
the case of this example, 00000002 is recorded as ID. 
This ID indicates route directory. 
[0095] In the case where Directory Records Block 
DRB consists of a plurality of blocks, the first directory 
records block entry is constituted with format as shown 
in FIG. 16, the last entry is constituted with format as 
shown in FIG. 18, and the entry therebetween is consti- 
tuted with format as shown in FIG. 17. 
[0096] In the format of FIG. 16, FO is recorded into 
the first 1 byte, and ID of 1 bite on the MSB side of ID 
of 4 bytes is recorded into the next 1 byte. Index to Next 
DRB is allocated to the next 2 bytes. 
[0097] In the entry of FIG. 17, FE is allocated to the 
first 1 byte and the next 1 byte is reserved (unused). 
Index to Next DRB is allocated to the remaining two 
bytes. 

[0098] In the entry of FIG. 18, FF is allocated to the 
first 1 byte, and ID of the remaining 3 bytes except for 
MSB of 1 byte recorded at the second byte of FIG. 16 
is recorded at the remaining 3 bytes. 
[0099] Entries indicated by No. 7, No. 8 and No. 10 of 
FIG. 14 are prescribed by the format shown in FIG. 16, 
17 or 18. 0008 is recorded into the last 2 bytes of the 
entry corresponding to block No. 7. This indicates that 
the next DRB where related data is recorded is Directory 
Records Block DRB indicated by No. 8. Moreover, 
OOOA (hexadecimal number) is recorded at the last 2 
bytes of the entry of the block corresponding to No. 8. 
This indicates that Directory Record Blocks of No. 10 
(value by decimal notation corresponding to A of hexa- 
decimal number) are successive. 
[0100] In addition, 00 is recorded at the second byte 
of No. 7. It is seen that since ID of 000005 is recorded 
at the entry corresponding to the block of No. 10, ID of 
directory prescribed by these three blocks is eventually 
00000005. 

[0101] FIG. 19 shows format of Extent Records Block 
Entry of the Management Table of FIG. 14. In this format, 
80 is allocated to the first 1 byte, the remaining two bytes 
are reserved (unused), and Used Count is allocated to 
the last 1 byte. This used count indicates the number of 
used extent records of records corresponding to num- 
bers of 0 to 63 of Extent Records Blocks of FIG. 20 which 
will be described later. 

[0102] In the Management Table of FIG. 14, entry cor- 
responding to the block indicated by No. 5 is represent- 
ed by the format of Extent Records Block Entry shown 
in FIG. 19. Value of 04 is recorded at the last 1 byte. 
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This indicates that the number of used Extent Records 
Blocks of Extent Records ER indicated by 64 numbers 
of 0 to 63 of the Extent Records Blocks shown in FIG. 
20 is 4 (respective Extent Records of Nos. 0,1,2,4 have 
been already used). 

[0103] Extent Records Block ERB shown in FIG. 13 
is constructed as shown in FIG. 20, for example. As 
shown in this figure, respective Extent Records Blocks 
ERB of 2 k bytes consist of 64 Extent Records ER indi- 
cated by No. 0 to No. 63 each having 32 bytes. 
[0104] Respective Extent Records ER consist of set 
of data of 4 bytes in which FFFF is recorded at the first 

1 byte and seven Extent Record Indexes shown in FIG. 
21 , or consist of set of eight Extent Descriptors of 4 bytes 
shown in FIG. 22. 

[0105] As shown in FIG. 21, Logical Block Offset is 
allocated to the first 2 bytes of Extent Records Index, 
Index to ERB is allocated to the next 2 bytes, and Offset 
of ER is allocated to the last 1 byte. 
[0106] In the data track, recording/reproduction of da- 
ta is carried out with Logical Block having 2048 bytes as 
a unit being as a minimum unit of logical write/read op- 
eration. Logical Block Offset indicates logical position 
from the lading portion within file of data indicated by 
index. Moreover, Index to ERB is of a structure of 10 
bits. Index to Extent Records Block ERB is indicated by 
anyone of numbers 0 to 1023. Offset of ER is of a struc- 
ture of 6 bits, and indicates any one of 64 Extent 
Records of Extent Records Block shown in FIG. 20. 
[0107] As shown in FIG. 22, Extent Start Location is 
allocated to the first 2 bytes of extent descriptor, and 
Number of Blocks is allocated to the remaining 2 bytes. 
This Extent Start Location indicates start position of file 
recorded in the Extent Area. In addition, Number of 
Blocks indicates No. of blocks of file which starts from 
the start position. 

[0108] In FIG. 20, Extent Record of 32 bytes indicated 
by No. 1 indicates index. FFFF is recorded at the leading 

2 bytes of the first 4 bytes. In the case of this example, 
0000 is allocated to the first 2 bytes of the next Extent 
Records Index as Logical Block Offset. In this case, 5 is 
stored as Index to ERB, and 2 is stored as Offset of ER. 
[0109] The fact that Offset of ER is 2 indicates that 
Extent Records indicated by No. 2 exists in FIG. 20. Its 
Logical Block Offset indicates 0000. This indicates that 
No. of the first block of file indicated in the Extent 
Records indicated by No. 2 is 0000 (i.e., the first block). 
In the Extent Records of No. 2, it is indicated that one 
block exists at the fifteenth block in terms of the absolute 
position (Extent Start Location) on data track at the lead- 
ing portion (left side in the figure), for example. 
[0110] It is to be noted that the fact that Index to ERB 
is 5 indicates that No. of Extent Records Block (shown 
in Fig. 20) is 5. 

[0111] The fact that the next Offset of ER is 4 indicates 
that data of Extent Records indicated by No. 4 exists. In 
this case, Logical Block Offset is 000B (11 in terms of 
decimal number). Namely, in this example, the total sum 



of blocks of Extent Records indicated by No. 2 is 11 (= 
1+1+2+1+1+1+3+1). For this reason, file starting from 
the twelfth block (block No. 11) exists at the position 
where Extent Start Location as an absolute position on 
5 mini-disc 1 recorded at the Extent Records indicated by 
No. 4 is 053C. 

[0112] It is to be noted that although only seven Extent 
Records can be represented by single Extent Records 
Index, in the case where the number of Extent Records 
10 increases beyond that, other Extent Record Indexes are 
further generated. Thus, index representing, as a set, a 
plurality of Extent Records Indexes is further generated. 
[0113] FIG. 23 shows, in a model form, the relation- 
ship between index and extent records recorded in the 
15 Extent Records Block. As shown in this figure, index of 
a predetermined Extent Records Block ERB is designat- 
ed from directory record of a predetermined Directory 
Records Block (Index to ER). At the designated index, 
seven indexes at the maximum are recorded. 
20 [0114] At respective indexes, start positions of 8 files 
at the maximum (Extent Start Location) and the num- 
bers of blocks constituting those files (Nos. of Blocks) 
are recorded. 

[0115] In this example, FAT as shown in FIG. 7 is not 
25 used. For this reason, U-TOC in this example is con- 
structed as shown in FIG. 24, for example. As is clear 
when FIG. 24 is compared to FIG. 3, LOFAT shown in 
FIG. 3 is not recorded at U-TOC of FIG. 24. Other for- 
mats of U-TOC are the same as the case shown in FIG. 
30 3. 

[0116] In this embodiment, bitmap as shown in FIG. 
25 is used in place of FAT. This bitmap is recorded at 
VSB of FIG. 13. 

[0117] In this example, one entry of bitmap consists 
35 of 2 bits. Similarly to the case of FAT shown in FIG. 7, 
respective entries corresponds to blocks of predeter- 
mined capacities (4 k bytes, 8 k bytes, 16 k bytes, 32 k 
bytes, or 64 k bytes) on mini-disc 1. Accordingly, the 
number of entries is formed by the number correspond- 
40 ing to the recording capacity of mini-disc 1 . 

[0118] At respective entries of 2 bits of the bitmap, da- 
ta of 2 bits which is indicated by any one of 00, 01 , 10 
and 11 is recorded. 00 indicates that corresponding 
block on mini-disc 1 is available and unused block. 01 
45 indicates that corresponding block on mini-disc 1 is used 
block where data has been already recorded. 10 indi- 
cates that corresponding block on mini-disc 1 includes 
any defective. In addition, 11 indicates that correspond- 
ing block on mini-disc 1 is disabled block (use of block 
50 is inhibited). 

[0119] As stated above, link information such as 
FFDh or No. of blocks to be linked is not recorded into 
the bitmap unlike FAT shown in FIGS. 7 and 8. Manage- 
ment of these information is carried out by the above- 
55 described directory information or file information (par- 
ticularly Extent Records ER). 

[0120] FIG. 26 shows an example of processing exe- 
cuted by host CPU 31 when mini-disc 1 (cartridge 1a) 
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is loaded into body 41 of mini-disc device for carrying 
out recording/reproduction of computer data to instruct 
initialization. Initially, at step S31, whether or not data 
track is formed on mini-disc 1 is judged. Whether or not 
data track is formed can be discriminated from track 
mode of U-TOC. In the case where any data track exists, 
since initialization for recording computer data has been 
already completed (recording area is ensured), initiali- 
zation processing has been completed. 
[0121] At step S31, in the case where it is judged that 
no data track is formed, the processing proceeds to step 
S32. At this step, empty area (empty parts table) is en- 
sured from U-TOC (data track is ensured). For example, 
a predetermined number of blocks are ensured as data 
track for recording computer data from empty area in 
the program area (whether or not a corresponding area 
is empty area can be seen from P-TN01 ~ P-TN0255 
of U-TOC). Namely, this area (parts table) is registered 
into, e.g., P-TN05, and start address and end address 
of that area are registered into the parts table. Further, 
data indicating that corresponding area is the area for 
recording computer data is registered into the area for 
track mode of the parts table. In addition, P-FRA of 
U-TOC is updated. 

[0122] As described above, the leading 16 clusters of 
the data track are caused to be VMA, and actual data is 
recorded into extent areas subsequent thereto (FIG. 
12). When the volume of the extent area is ensured by, 
e.g., 10 clusters, the area of 26 clusters in total (= 
16+10) are caused to be data track. 
[0123] Then, the processing proceeds to step S33. At 
this step, bitmap is written into VSB (FIG. 13) of VMA 
(FIG. 12) consisting of the leading 1 6 clusters of the data 
track ensured at step S32. In the bitmap, data is written 
as shown in FIG. 25. 

[0124] Namely, data (01) indicating used block is re- 
corded into the entry corresponding to 1 6 clusters where 
VMA is written. Data (00) signifying available unused 
block is recorded into the entry of bitmap corresponding 
to 50 clusters (area for recording primary computer da- 
ta) on the extent area. In addition, data (11) signifying 
disabled block is recorded into the entry of bitmap cor- 
responding to block on the extent area except for the 
above. 

[0125] It is to be noted that in the case where bitmap 
data is used for management of data track, bitmap data 
is stored into memory 1 7 of FIG. 2, and is recorded into 
bitmap on mini-disc 1 at a predetermined timing. 
[0126] FIG. 27 shows an example of processing exe- 
cuted by host CPU 31 in the case where computer data 
is recorded onto mini-disc 1. Initially, at step S41, host 
CPU 31 reads in data of bitmap recorded on mini-disc 
1. As described above, volume management area in- 
cluding data of bitmap is formed at the leading portion 
of data track initially formed in the program area. Thus, 
there is employed a method of detecting start address 
of parts table corresponding to the leading portion of da- 
ta track initially formed from U-TOC to read out volume 



descriptor on the basis of this start address to read out 
bitmap on the basis of position information of bitmap re- 
corded thereat, thereby making it possible to read bit- 
map into host CPU 31. This bitmap data is temporarily 
5 stored into memory 17. Thus, host CPU 31 reads there- 
into this data at a predetermined timing. 
[0127] Then, the processing proceeds to step S42. At 
this step, whether or not there is available unused entry 
(block of 00) in the bitmap currently read in is judged. In 
the case where computer data is initially recorded, since 
available unused block exists, the processing proceeds 
from step S42 to step S45. At step S45, one entry (e.g., 
entry 80 of bitmap of FIG. 28) is selected from unused 
blocks to allow this entry to correspond to file into which 
data is to be written. Then, data is actually written into 
block on the extent area to which that entry corresponds. 
[0128] Then, the processing proceeds to step S46. At 
this step, data (01 ) indicating used area is recorded into 
the entry of bitmap corresponding to block of the extent 
area where recording is carried out (FIG. 28). Further, 
the processing proceeds to step S47 to register block of 
that extent area into the extent record ER (FIG. 1 3, FIG. 
20). 

[0129] Then, the processing proceeds from step S47 
to step S48. At the step S48, whether or not writing of 
all data is completed is judged. Unless such a writing is 
completed, the processing returns to step S42. An op- 
eration as described above will be repeated. 
[0130] The state of bitmap in the case where data is 
recorded into block of extent area corresponding to en- 
tries 80 to 89 on bitmap in a manner stated above is 
shown in FIG. 28. 

[0131] In the case where ensured area is filled with 
data as the result of repetition of the above-described 
operation, and it is judged at step S42 that entry indicat- 
ing available unused block does not exist in the bitmap, 
i.e., when there is no empty area for recording computer 
data, the processing proceeds to step S43 to ensure 
empty area of U-TOC to supplement that empty area as 
data track for recording computer data. Then, the 
processing proceeds to step S44 to register block of the 
supplemented area of the data track as available un- 
used block. Namely, processing similar to those at steps 
S32, S33 in the initialization processing of FIG. 26 is 
carried out to newly ensure (supplement) data recording 
area of 12 blocks. It is to be noted that the number of 
blocks supplemented at this time is arbitrary. In this 
case, however, since bitmap has been already pre- 
pared, only data corresponding thereto is updated with- 
out newly preparing such bitmap. 
[0132] In the case where it is judged at step S48 that 
writing of all data has been completed, the processing 
is completed. 

[0133] In the above-described respective embodi- 
ments, in the case where unit for carrying out manage- 
ment by FAT or bitmap is a value smaller than one clus- 
ter, in order to record data with respect to one unit, body 
41 once reads out data of one cluster including that unit 
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from mini-disc 1 to store it into RAM 1 3. Then, data cor- 
responding to that unit is transferred from host CPU 31 , 
and is then newly stored into RAM 1 3. Then, data of one 
cluster which has been read out from RAM 1 3 is written 
into mini-disc 1 . Namely, recording in a unit substantially 
smaller than one cluster can be made. On the other 
hand, reproduction is carried out in sector unit. 
[0134] It is to be noted that while management of re- 
cording data with respect to writable mini-disc 1 has 
been described in the above-described embodiments, 
recording data management of the above-described 
embodiments can be also applied to mini-disc 1 dedi- 
cated to read-out. It should be noted that no U-TOC area 
is provided with respect to mini-disc 1 dedicated to read- 
out. Thus, there is employed a scheme to set table of a 
structure substantially similar to U-TOC of the above- 
described embodiments in the TOC area to set VMA 
similar to the above-described embodiments in the pro- 
gram area, thereby to realize the above-described re- 
cording data management. 

Industrial Applicability 

[0135] As stated above, in accordance with the re- 
cording medium management method of this invention, 
a scheme is employed to designate a predetermined 
range from the range of recording medium caused to 
undergo management in accordance with first table to 
carry out management of recording state onto recording 
medium of digital data having second unit as reference 
in accordance with second table. Accordingly, it is pos- 
sible to ensure compatibility with recording medium on 
which digital data is recorded with the first unit being as 
reference. Further, if there is any empty area in the re- 
cording medium, it is possible to supplement digital data 
in the area to record it. 

[0136] Further if the second unit is caused to be small- 
er than the first unit, it is possible to record data in a 
processing unit smaller than a processing unit set in ad- 
vance. 

[0137] In addition, in the case where the second unit 
is caused to have the same size as that of the second 
unit, a scheme is employed to register one large track 
into the first table to partition this track into much more 
plural areas on the second table so that there are pro- 
vided partitions more than partitionable numbers in the 
first table (255 of P-TN01 to P-TN0255 in the case of 
the above-mentioned embodiment), thus making it pos- 
sible to record data. 



Claims 

1. A recording medium management method for car- 
rying out the management of recording digital data 
with respect to a recording medium (1), 

wherein the management of the recording of 
digital data onto said recording medium where re- 



cording is carried out in first data recording units 
(CLUSTER) is carried out in accordance with a first 
table (MANAGEMENT TABLE), 
characterized in that 

5 

a designated area of said recording medium (1) 
which undergo management in accordance 
with said first table is to be recording by digital 
data in second data recording units (BLOCK), 
10 - the management of the recording of digital data 
onto said recording medium (1) in said desig- 
nated area where recording is carried out in 
second data units is carried out in accordance 
with a second table (PAT; BITMAP), and 
15 - data corresponding to the respective second 
data recording units are formed in said second 
table and said second table includes informa- 
tion indicating whether or not digital data have 
already been recorded in the corresponding 
20 second data recording units of said recording 

medium (1). 

2. The recording medium management method as set 
forth in claim 1, 

25 wherein the second data recording unit (BLOCK) is 
smaller than the first data recording unit (CLUS- 
TER). 

3. The recording medium management method as set 
30 forth in claim 1 or 2, 

wherein said first data recording unit is a cluster and 
said second data recording unit is a block. 

4. The recording medium management method as set 
35 forth in claim 1 , 

wherein the second data recording unit is of the 
same size as that of the first data recording unit. 

5. The recording medium management method as set 
40 forth in any one of claims 1 to 4, 

wherein the first table is recorded in U-TOC or TOC 
of the recording medium (1), and 
wherein the second table is recorded in the area 
caused to undergo management by the second ta- 
45 ble of the recording medium (1 ). 

6. The recording medium management method as set 
forth in claim 5, 

wherein a pointer indicating the recording position 
50 of the second table (FAT; BITMAP) is recorded in 
said U-TOC or TOC. 

7. The recording medium management method as set 
forth in any one of claims 1 to 6, 

55 wherein different kinds of digital data are respec- 
tively recorded in the area caused to undergo man- 
agement by the first table and in the area caused to 
undergo management by the second table. 
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8. The recording medium management method as set 
forth in claim 7, 

wherein audio digital data is recorded in the area 
caused to undergo management only by the first ta- 
ble, and 

wherein digital data processed by computer is re- 
corded into the area caused to undergo manage- 
ment by the second table. 

9. The recording medium management method as set 
forth in any one of claims 1 to 8, 

wherein data corresponding to the respective sec- 
ond dta recording units (BLOCK) are formed in the 
second table (FAT; BITMAP). 

10. The recording medium management method as set 
forth in claim 9, 

wherein data corresponding to the respective sec- 
ond data recording units include information indicat- 
ing that digital data has been already used in the 
corresponding second data recording units of the 
recording medium (1). 

1 1 . The recording medium management method as set 
forth in claim 9, 

wherein data corresponding to the respective sec- 
ond data recording units include information indicat- 
ing that the corresponding second data recording 
units of the recording medium (1) are disabled. 

12. The recording medium management method as set 
forth in claim 9, 

wherein data corresponding to the respective sec- 
ond data recording units include information indicat- 
ing that the corresponding second data recording 
units of the recording medium (1) are defective. 

13. The recording medium management method as set 
forth in claim 10, 11 or 12, 

wherein link information within the second table is 
further recorded in the second table. 

14. The recording medium management method as set 
forth in any one of claims 1 to 13, wherein in the 
case where an unrecorded area is insufficient in any 
one of the area where recording is carried out in first 
data recording units and the area where recording 
is carried out in second data recording units, the re- 
spective other area is changed to said one area on 
the first or second table, respectively. 

15. The recording medium management method as set 
forth in claim 5, 

wherein the U-TOC or TOC is recorded in a fixed 
area of the recording medium (1). 

16. The recording medium management method as set 
forth in claim 5, 



wherein said second table is bitmap. 

17. The recording medium management method as set 
forth in claim 5, 

5 wherein information indicating position of the sec- 
ond table is recorded immediately before the sec- 
ond table. 

18. The recording medium management method ac- 
10 cording to anyone of the preceding claims, which 

comprises furthermore the steps of: 

detecting (S31)an empty area of the recording 
medium (1 ) from data of said first table; 
15 recording, into the first table, data indicating 

that the empty area is caused to serve as tracks 
for digital data; and 

preparing (S33) said second table indicating 
use state of data of the recording medium (1) 
20 at the leading portion of the empty area caused 

to serve as the tracks for digital data. 

19. The recording medium management method ac- 
cording to claim 18, wherein whether or not any 

25 track for digital data already exists is judged from 
data of said first table. 

20. The recording medium management method ac- 
cording to claim 18, 

30 wherein information indicating position of the sec- 
ond table is recorded immediately before said sec- 
ond table. 

21. The recording medium management method ac- 
35 cording to claim 18, 

wherein the second table is bitmap, the bitmap in- 
cluding information indicating that the second data 
recording unit is available. 

40 22. The recording medium management method ac- 
cording to claim 18, wherein the second table is bit- 
map, the bitmap including information indicating 
that the second data recording unit has been al- 
ready used. 

45 

23. The recording medium management method ac- 
cording to claim 18, wherein the second table is bit- 
map, the bitmap including information indicating 
that the second data recording unit is defective. 

50 

24. The recording medium management method ac- 
cording to claim 18, wherein the second table is bit- 
map, the bitmap including information indicating 
that the second data recording unit is disabled. 

55 

25. The recording medium management method ac- 
cording to anyone of the preceding claims, 

the method furthermore comprising the steps of: 
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reading out, on the basis of data of said first 
table, said second table from tracks for digital 
data of the recording medium (1); 
detecting (S42) information indicating an avail- 
able block from the second table; 
recording digital data in blocks of the tracks for 
digital data corresponding to the information in- 
dicating said available block; 
and 

rewriting (S47) the information indicating said 
available block of the second table into infor- 
mation indicating an disabled block. 

26. The recording medium management method ac- 
cording to claim 25, 

wherein in the case where the information indicating 
an available block is not included in the second ta- 
ble, 

the method comprises the steps of: 

detecting (S43) an empty area of the recording 
medium (1 ) from data of the first table; 
recording, into the first table, data indicating 
that the empty area is caused to be tracks for 
digital data; and 

recording (S47) information indicating an avail- 
able block into the area for data of the second 
table corresponding to the block of the empty 
area caused to be the tracks for digital data. 

27. The recording medium management method ac- 
cording to claim 25, the method comprising the 
steps of: 

reading out, on the basis of the first table, infor- 
mation indicating position of the second table 
recorded immediately before the second table; 
reading out the second table on the basis of in- 
formation indicating the position of the second 
table. 

28. The recording medium management method ac- 
cording to claim 24, the method furthermore com- 
prising the steps of: 

reading out digital data of first data recording 
units caused to undergo management by said 
first table from the recording medium (1); 
storing the digital data of the first data recording 
units into a memory (16); 
updating at least one portion of the digital data 
of the first data recording units stored in said 
memory (16) by new digital data every second 
unit less than the first unit, which is caused to 
undergo management by said second table; 
and 

recording new digital data of the first units in- 
cluding the new digital data stored in said mem- 



ory (16) onto the recording medium (1). 

29. A system for recording and/or reproducing digital 
data onto and from a recording medium (1 ) respec- 

5 tively, according to the method according to anyone 
of claims 1 to 28, comprising: 

recording means (3-6) for recording : a first ta- 
ble (MANAGEMENT TABLE) for managing dig- 
ital data recorded in a designated area in first 
data recording units (CLUSTER); 
a second table (PAT; BITMAP) for managing 
digital data in said designated area which are 
recorded in second data recording units 
(BLOCK) and including information whether or 
not digital data have already been recorded in 
the corresponding second data recording units; 
and the digital data onto the recording medium 
(1); 

reproducing means (3-6) for reproducing said 
first table, said second table and said digital da- 
ta recorded on the recording medium (1); 
memory means (16, 17) for storing said first ta- 
ble and said second table; and 
control means (11, 12) for controlling the re- 
cording and/or reproducing means (3-6), ac- 
cording to said first and second tables. 

30. A recording medium having recorded thereon : a 
first table (MANAGEMENT TABLE) for managing 
digital data recorded in a designated area in first da- 
ta recording units (CLUSTER); 

a second table (PAT; BITMAP) for managing digital 
data in said designated area which are recorded in 
second data recording units (BLOCK) and including 
information whether or not digital data have already 
been recorded in the corresponding second data re- 
cording units; and digital data all recorded in ac- 
cordance with the management method according 
to anyone of claims 1 to 28. 



Patentanspruche 

45 1. Aufzeichnungstrager-Verwaltungsverfahren zur 
Durchfuhrung der Verwaltung bzw. des Manage- 
ments der Aufzeichnung von digitalen Daten in be- 
zug auf einen Aufzeichnungstrager (1), wobei die 
Verwaltung der Aufzeichnung der digitalen Daten 

50 auf dem betreffenden Aufzeichnungstrager, auf 
dem eine Aufzeichnung in ersten Date n auf zeich- 
nungseinheiten (CLUSTER) ausgefuhrt wird, ent- 
sprechend einer ersten Tabelle (Verwaltungstabel- 
le) ausgefuhrt wird, 

55 dadurch gekennzeichnet, 

dass in einem bestimmten Bereich des betref- 
fenden Aufzeichnungstragers (1 ), der eine Ver- 
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waltung entsprechend der genannten ersten 
Tabelle erfahrt, digitale Daten in zweiten Daten- 
aufzeichnungseinheiten (BLOCK) aufzuzeich- 
nen sind, 

dass die Verwaltung der Aufzeichnung der di- 
gitalen Daten . auf dem betreffenden Aufzeich- 
nungstrager(l) in dem genannten bestimmten 
Bereich, in welchem eine Aufzeichnung in 
zweiten Dateneinheiten durchgefuhrt wird, ent- 
sprechend einer zweiten Tabelle (FAT; BIT- 
MAP) vorgenommen wird 
und dass Daten entsprechend den betreffen- 
den zweiten Datenaufzeichnungseinheiten in 
der genannten zweiten Tabelle gebildet wer- 
den, die Informationen enthalt, welche ange- 
ben, ob digitale Daten bereits in den entspre- 
chenden zweiten Datenaufzeichnungseinhei- 
ten des genannten Aufzeichnungstragers (1) 
aufgezeichnet worden sind oder nicht. 

2. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 1 , wobei die zweite Datenaufzeichnungs- 
einheit (BLOC) kleiner ist als die erste Datenauf- 
zeichnungseinheit (CLUSTER). 

3. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 1 oder 2, wobei die genannte erste Da- 
tenaufzeichnungseinheit ein Cluster ist und wobei 
die genannte zweite Datenaufzeichnungseinheit 
ein Block ist. 

4. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 1 , wobei die zweite Datenaufzeichnungs- 
einheit von derselben Grblie ist wie jene der ersten 
Datenaufzeichnungseinheit. 

5. Aufzeichnungstrager-Verwaltungsverfahren nach 
einem der Anspruche 1 bis 4, wobei die erste Ta- 
belle in U-TOC oder TOC des Aufzeichnungstra- 
gers (1) aufgezeichnet wird und wobei die zweite 
Tabelle in dem Bereich aufgezeichnet wird, der ver- 
anlafct wird, eine Verwaltung durch die zweite Ta- 
belle des Aufzeichnungstragers (1) zu erfahren. 

6. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 5, wobei ein auf die Aufzeichnungsposi- 
tion der zweiten Tabelle (FAT; BITMAP) hinweisen- 
der Zeiger in U-TOC oder TOC aufgezeichnet wird. 

7. Aufzeichnungstrager-Verwaltungsverfahren nach 
einem der Anspruche 1 bis 6, wobei unterschiedli- 
che Arten von digitalen Daten in dem Bereich, der 
veranlafit wird, eine Verwaltung durch die erste Ta- 
belle zu erfahren, und in dem Bereich aufgezeich- 
net werden, der veranlafct wird, eine Verwaltung 
durch die zweite Tabelle zu erfahren. 

8. Aufzeichnungstrager-Verwaltungsverfahren nach 



Anspruch 7, wobei digitale Audiodaten in dem Be- 
reich aufgezeichnet werden, der veranlaftt wird, ei- 
ne Verwaltung lediglich durch die erste Tabelle zu 
erfahren, 

5 und wobei durch einen Computer verarbeitete digi- 
tale Daten in dem Bereich aufgezeichnet werden, 
der veranlaftt wird, eine Verwaltung durch die zwei- 
te Tabelle zu erfahren. 

10 9. Aufzeichnungstrager-Verwaltungsverfahren nach 
einem der Anspruche 1 bis 8, wobei Daten, die den 
betreffenden zweiten Datenaufzeichnungseinhei- 
ten (BLOCK) entsprechen, in der zweiten Tabelle 
(FAT; BITMAP) gebildet werden. 

15 

10. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 9, wobei Daten, die den betreffenden 
zweiten Datenaufzeichnungseinheiten entspre- 
chen, eine Information enthalten, welche anzeigt, 

20 dass digitale Daten in den entsprechenden zweiten 
Datenaufzeichnungseinheiten des Aufzeichnungs- 
tragers (1) bereits verwendet worden sind. 

11. Aufzeichnungstrager-Verwaltungsverfahren nach 
25 Anspruch 9, wobei Daten, die den betreffenden 

zweiten Datenaufzeichnungseinheiten entspre- 
chen, eine Information enthalten, die anzeigt, dass 
die entsprechenden zweiten Datenaufzeichnungs- 
einheiten des Aufzeichnungstragers (1 ) unwirksam 
30 gemacht sind. 

12. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 9, wobei Daten, die den betreffenden 
zweiten Datenaufzeichnungseinheiten entspre- 

35 chen, eine Information enthalten, die anzeigt, dass 
die entsprechenden zweiten Datenaufzeichnungs- 
einheiten des Aufzeichnungstragers (1) fehlerhaft 
sind. 

40 13. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 10, 11 oder 12, wobei ferner eine Ket- 
tungsinformation innerhalb der zweiten Tabelle in 
der zweiten Tabelle aufgezeichnet wird. 

45 14. Aufzeichnungstrager-Verwaltungsverfahren nach 
einem der Anspruche 1 bis 13, wobei in dem Fall, 
dass ein aufzeichnungsfreier Bereich in irgendei- 
nem Bereich; der den Bereich, in welchem eine Auf- 
zeichnung in ersten Datenaufzeichnungseinheiten 

50 ausgefuhrt wird, und den Bereich, in welchem eine 
Aufzeichnung in zweiten Datenaufzeichnungsein- 
heiten ausgefuhrt wird, umfasst, unzureichend ist, 
der betreffende andere Bereich in den genannten 
einen Bereich in der ersten oder zweiten Tabelle ge- 

55 andert wird. 

1 5. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 5, wobei die U-TOC- oder TOC-Angabe 
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in einem festliegenden Bereich des Aufzeichnungs- 
tragers (1) aufgezeichnet wird. 

16. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 5, wobei die genannte zweite Tabelle ein 5 
Bitmap ist. 

17. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 5, wobei die Information, welche die Po- 
sition der zweiten Tabelle anzeigt, unmittelbar vor 10 
der zweiten Tabelle aufgezeichnet wird. 

18. Aufzeichnungstrager-Verwaltungsverfahren nach 
einem der vorhergehenden Anspruche, umfassend 
ferner die Schritte: 15 

Ermitteln (S31) eines Leerbereiches des Auf- 
zeichnungstragers (1) aus Daten der genann- 
ten ersten Tabelle, 

Aufzeichnen von Daten in der ersten Tabelle, 20 
die anzeigen, dass der Leerbereich veranlafit 
wird, als Spuren fur digitale Daten zu dienen, 
und Bereitstellen (S33) dergenannten zweiten 
Tabelle, die den Nutzungszustand von Daten 
des Aufzeichnungstragers (1) im Anfangsteil 25 
des Leerbereiches anzeigt, der veranlalit wird, 
als Spuren fur digitale Daten zu dienen. 

19. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 18, wobei eine Entscheidung daruber, ob 30 
irgendeine Spur fur digitale Daten bereits existiert 
oder nicht, aus Daten der betreffenden ersten Ta- 
belle getroffen wird. 

20. Aufzeichnungstrager-Verwaltungsverfahren nach 35 
Anspruch 18, wobei eine Information, welche die 
Position der zweiten Tabelle anzeigt, unmittelbar 
vor der betreffenden zweiten Tabelle aufgezeichnet 
wird. 

40 

21 . Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 18, wobei die zweite Tabelle ein Bitmap 
ist, das eine Information enthalt, welche anzeigt, 
dass die zweite Datenaufzeichnungseinheit verfug- 
bar ist. 45 

22. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 18, wobei die zweite Tabelle ein Bitmap 
ist, das eine Information enthalt, welche anzeigt, 
dass die zweite Datenaufzeichnungseinheit bereits 50 
verwendet worden ist. 

23. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 18, wobei die zweite Tabelle ein Bitmap 

ist, das eine Information enthalt, welche anzeigt, 55 
dass die zweite Datenaufzeichnungseinheit fehler- 
haft ist. 



24. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 18, wobei die zweite Tabelle ein Bitmap 
ist, das eine Information enthalt, welche anzeigt, 
dass die zweite Datenaufzeichnungseinheit unwirk- 
sam gemacht ist. 

25. Aufzeichnungstrager-Verwaltungsverfahren nach 
einem der vorhergehenden Anspruche, umfassend 
ferner die Verfahrensschritte: 

Auslesen der genannten zweiten Tabelle aus 
Spuren fur digitale Daten des Aufzeichnungs- 
tragers (1 ) auf der Grundlage von Daten derge- 
nannten ersten Tabelle, 
Ermitteln (S42) einer Information, die einen ver- 
fugbaren Block anzeigt, aus der zweiten Tabel- 
le, 

Aufzeichnen von digitalen Daten in Blocken der 
Spuren fur digitale Daten entsprechend der den 
betreffenden verfugbaren Block anzeigenden 
Information 

und Neuschreiben (S47) der den betreffenden 
verfugbaren Block der zweiten Tabelle anzei- 
genden Information in eine einen unwirksam 
gemachten Block anzeigende Information. 

26. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 25, wobei das Verfahren in dem Fall, dass 
die einen verfugbaren Block anzeigende Informati- 
on nicht in der zweiten Tabelle enthalten ist, die 
Schritte umfasst: 

Ermitteln (S43) eines Leerbereiches des Auf- 
zeichnungstragers (1 ) aus Daten der ersten Ta- 
belle, 

Aufzeichnen von Daten, die angeben, dass der 
Leerbereich veranlafit wird, Spuren fur digitale 
Daten zu sein, in der ersten Tabelle, 
und Aufzeichnen (S47) einer einen verfugba- 
ren Block anzeigenden Information in dem Be- 
reich fur Daten der zweiten Tabelle entspre- 
chend dem Block des Leerbereiches, der ver- 
anlafit wird, Spuren fur digitale Daten zu sein. 

27. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 25, umfassend die Verfahrensschritte 
des Auslesens einer die Position der zweiten Tabel- 
le angebenden Information, welche unmittelbar vor 
der zweiten Tabelle aufgezeichnet ist, auf der 
Grundlage der ersten Tabelle, 

und Auslesen der zweiten Tabelle auf der Grundla- 
ge einer die Position der zweiten Tabelle angeben- 
den Information. 

28. Aufzeichnungstrager-Verwaltungsverfahren nach 
Anspruch 24, ferner umfassend die Verfahrens- 
schritte: 
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Auslesen von digitalen Daten derersten Daten- 
aufzeichnungseinheiten von dem Aufzeich- 
nungstrager (1), die veranlaftt werden, eine 
Verwaltung durch die erste Tabelle zu erfahren, 
Speichern der digitalen Daten der ersten Da- 5 
tenaufzeichnungseinheiten in einem Speicher 
(16), 

Aktualisieren zumindest eines Teiles der digita- 
len Daten der ersten Datenaufzeichnungsein- 
heiten, die in dem genannten Speicher(16) ge- 10 
speichert sind, durch neue digitale Daten jeder 
zweiten Einheit weniger als durch die erste Ein- 
heit, welche veranlafit wird, eine Verwaltung 
durch die zweite Tabelle zu erfahren, 
und Aufzeichnen von neuen digitalen Daten der 15 
ersten Einheiten, welche die in dem genannten 
Speicher (16) gespeicherten neuen digitalen 
Daten enthalten, auf dem Aufzeichnungstrager 
d). 

20 

29. System zur Aufzeichnung und/oder Wiedergabe 
von digitalen Daten auf bzw. von einem Aufzeich- 
nungstrager (1 ) gemaQ) dem Verfahren nach einem 
der Anspruche 1 bis 28, umfassend Aufzeichnungs- 
einrichtungen (3-6) zur Aufzeichnung einer ersten 25 
Tabelle (Verwaltungstabelle) fur die Verwaltung von 
digitalen Daten, die in einem bestimmten Bereich in 
ersten Datenaufzeichnungseinheiten (CLUSTER) 
aufgezeichnet sind, einerzweiten Tabelle (FAT; BIT- 
MAP) zur Verwaltung von digitalen Daten in dem 30 
betreffenden bestimmten Bereich, die in zweiten 
Datenaufzeichnungseinheiten (BLOCK) aufge- 
zeichnet sind und die eine Information daruber ent- 
halten, ob digitale Daten in den entsprechenden 
zweiten Datenaufzeichnungseinheiten bereits auf- 35 
gezeichnet worden sind oder nicht, 

und der digitalen Daten auf dem Aufzeichnungstra- 
ger (1 ), Wiedergabeeinrichtungen (3-6) zur Wieder- 
gabe der auf dem Aufzeichnungstrager (1) aufge- 
zeichneten ersten Tabelle, zweiten Tabelle und der 40 
genannten digitalen Daten, Speichereinrichtungen 
(1 6, 1 7) zur Speicherung der genannten ersten Ta- 
belle und der genannten zweiten Tabelle 
und Steuereinrichtungen (11, 12)zurSteuerung der 
Aufzeichnungs- und/oder Wiedergabeeinrichtun- 45 
gen (3-6) entsprechend den genannten ersten und 
zweiten Tabellen. 

30. Aufzeichnungstrager, auf dem eine erste Tabelle 
(Verwaltungstabelle) fur die Verwaltung von digita- 50 
len Daten, die in einem bestimmten Bereich in er- 
sten Datenaufzeichnungseinheiten (CLUSTER) 
aufgezeichnet sind, 

eine zweite Tabelle (FAT; BITMAP) zur Verwaltung 
von digitalen Daten in dem betreffenden bestimm- 55 
ten Bereich, die in zweiten Datenaufzeichnungsein- 
heiten (BLOCK) aufgezeichnet sind und die eine In- 
formation daruber enthalten, ob digitale Daten in 



den entsprechenden zweiten Datenaufzeichnungs- 
einheiten bereits aufgezeichnet worden sind oder 
nicht, 

und digitale Daten aufgezeichnet sind, wobei die 
betreffenden Tabellen und die genannten Daten alle 
entsprechend dem Verwaltungsverfahren nach ei- 
nem der Anspruche 1 bis 28 aufgezeichnet sind. 



Revendications 

1. Procede de gestion d'un support d'enregistrement 
pour effectuer la gestion de donnees numeriques 
d'enregistrement par rapport a un support d'enre- 
gistrement (1), dans lequel la gestion de I'enregis- 
trement de donnees numeriques sur ledit support 
d'enregistrement, ou I'enregistrement est execute 
dans des premieres unites d'enregistrement de 
donnees (CLUSTER), est executee en conformite 
avec une premiere table (TABLE DE GESTION), 
caracterise en ce que : 

une zone determinee dudit support d'enregis- 
trement (1), qui subit une gestion conforme- 
ment a ladite premiere table, est destinee a etre 
enregistree avec des donnees numeriques 
dans les deuxiemes unites d'enregistrement de 
donnees (BLOC), 

la gestion de I'enregistrement de donnees nu- 
meriques sur ledit support d'enregistrement (1 ) 
dans ladite zone determinee, ou I'enregistre- 
ment est execute dans des deuxiemes unites, 
est executee conformement a une deuxieme 
table (PAT; BITMAP), et 
des donnees correspondant aux deuxiemes 
unites d'enregistrement de donnees respecti- 
ves sont formees dans ladite deuxieme table et 
ladite deuxieme table comprend des informa- 
tions indiquant le fait que des donnees nume- 
riques aient deja ete enregistrees ou non dans 
les deuxiemes unites d'enregistrement de don- 
nees correspondantes dudit support d'enregis- 
trement (1). 

2. Procede de gestion d'un support d'enregistrement 
selon la revendication 1, dans lequel la deuxieme 
unite d'enregistrement de donnees (BLOC) est plus 
petite que la premiere unite d'enregistrement de 
donnees (CLUSTER). 

3. Procede de gestion d'un support d'enregistrement 
selon la revendication 1 ou 2, dans lequel ladite pre- 
miere unite d'enregistrement de donnees est un- 
cluster et ladite deuxieme unite d'enregistrement de 
donnees est un bloc. 

4. Procede de gestion d'un support d'enregistrement 
selon la revendication 1, dans lequel la deuxieme 
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unite d'enregistrement de donnees a la meme di- 
mension que celle de la premiere unite d'enregis- 
trement de donnees. 

5. Procede de gestion d'un support d'enregistrement 
selon I'une quelconque des revendications 1 a 4, 
dans lequel la premiere table est enregistree dans 
U-TOC ou TOC du support d'enregistrement (1) et 
dans lequel. la deuxieme table est enregistree dans 
la zone destinee a subir la gestion par la deuxieme 
table du support d'enregistrement (1). 

6. Procede de gestion d'un support d'enregistrement. 
selon la revendication 5, dans lequel un pointeur in- 
diquant la position d'enregistrement de la deuxieme 
table (PAT; BITMAP) est enregistre dans ledit 
U-TOC ou TOC. 

7. Procede de gestion d'un support d'enregistrement 
selon I'une quelconque des revendications 1 a 6,. 
dans lequel differents types de donnees numeri- 
ques sont respectivement enregistres dans la zone 
destinee a subir la gestion par la premiere table et 
dans la zone destinee a subir la gestion par la 
deuxieme table. 

8. Procede de gestion d'un support d'enregistrement 
selon la revendication 7, dans lequel des donnees 
numeriques audio sont enregistrees dans la zone 
destinee a subir la gestion par la premiere table, et 
dans lequel des donnees numeriques elaborees 
par ordinateur sont enregistrees dans la zone des- 
tinee a subir la gestion par la deuxieme table. 

9. Procede de gestion d'un support d'enregistrement 
selon I'une quelconque des revendications 1 a 8, 
dans lequel les donnees correspondant aux deuxie- 
mes unites d'enregistrement de donnees respecti- 
ves (BLOC) sont formees dans la deuxieme table 
(FAT; BITMAP). 

10. Procede de gestion d'un support d'enregistrement 
selon la revendication 9, dans lequel les donnees 
correspondant aux deuxiemes unites d'enregistre- 
ment de donnees respectives comprennent des in- 
formations indiquant que des donnees numeriques 
ont deja ete utilisees dans les deuxiemes unites 
d'enregistrement de donnees correspondantes du 
support d'enregistrement (1). 

11. Procede de gestion d'un support d'enregistrement 
selon la revendication 9, dans lequel les donnees 
correspondant aux deuxiemes unites d'enregistre- 
ment de donnees respectives comprennent des in- 
formations indiquant que les deuxiemes unites 
d'enregistrement de donnees correspondantes du 
support d'enregistrement (1) sont invalidees. 



12. Procede de gestion d'un support d'enregistrement 
selon la revendication 9, dans lequel les donnees 
correspondant aux deuxiemes unites d'enregistre- 
ment de donnees respectives comprennent des in- 

5 formations indiquant que les deuxiemes unites 
d'enregistrement de donnees correspondantes du 
support d'enregistrement (1) sont defectueuses. 

13. Procede de gestion d'un support d'enregistrement 
10 selon la revendication 10, 11 ou 12, dans lequel des 

informations de liaison a I'interieur de la deuxieme 
table sont enregistrees en outre dans la deuxieme 
table. 

15 14. Procede de gestion d'un support d'enregistrement 
selon I'une quelconque des revendications 1 a 13, 
dans lequel, dans le cas ou une zone non enregis- 
tree serait insuffisante dans I'une quelconque des 
zones dans lesquelles I'enregistrement est execute 
20 dans des premieres unites d'enregistrement de 
donnees et des zones dans lesquelles I'enregistre- 
ment est execute dans des deuxiemes unites d'en- 
registrement de donnees, I'autre zone respective 
est changee en ladite une zone sur la premiere ou 
25 deuxieme table, respectivement. 

15. Procede de gestion d'un support d'enregistrement 
selon la revendication 5, dans lequel le U-TOC ou 
TOC est enregistre dans une zone fixe du support 

30 d'enregistrement (1 ). 

16. Procede de gestion d'un support d'enregistrement 
selon la revendication 5, dans lequel ladite deuxie- 
me table est bitmap. 

35 

17. Procede de gestion d'un support d'enregistrement 
selon la revendication 5, dans lequel des informa- 
tions indiquant une position de la deuxieme table 
sont enregistrees immediatement avant la deuxie- 

40 me table. 

18. Procede de gestion d'un support d'enregistrement 
selon I'une quelconque des revendications prece- 
dentes, qui comprend en outre les etapes consis- 
ts tant a : 

detecter (S31 ) une zone vide du support, d'en- 
registrement (1 ) a partir des donnees de ladite 
premiere table ; 
50 enregistrer, dans la premiere table, des don- 

nees indiquant que la zone vide est destinee a 
servir de pistes pour les donnees numeriques ; 
et 

preparer (S33) ladite deuxieme table indiquant 
55 I'etat d'utilisation de donnees du support d'en- 

registrement (1) au niveau de la partie de tete 
de la zone vide destinee a servir de pistes pour 
les donnees numeriques. 
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19. Procede de gestion d'un support d'enregistrement 
selon la revendication 18, dans lequel le fait qu'il 
existe deja ou non une quelconque piste pour des 
donnees numeriques est determine a partir des 
donnees de ladite premiere table. 

20. Procede de gestion d'un support d'enregistrement 
selon la revendication 18, dans lequel les informa- 
tions indiquant la position de la deuxieme table sont 
enregistrees immediatement avant ladite deuxieme 
table. 

21. Procede de gestion d'un support d'enregistrement 
selon la revendication 18, dans lequel la deuxieme 
table est bitmap, le bitmap comprenant des infor- 
mations indiquant que la deuxieme unite d'enregis- 
trement de donnees est disponible. 

22. Procede de gestion d'un support d'enregistrement 
selon la revendication 18, dans lequel la deuxieme 
table est bitmap, le bitmap comprenant des infor- 
mations indiquant que la deuxieme unite d'enregis- 
trement de donnees a deja ete utilisee. 

23. Procede de gestion d'un support d'enregistrement 
selon la revendication 18, dans lequel la deuxieme 
table est bitmap, le bitmap comprenant des infor- 
mations indiquant que la deuxieme unite d'enregis- 
trement de donnees est defectueuse. 

24. Procede de gestion d'un support d'enregistrement 
selon la revendication 18, dans lequel la deuxieme 
table est bitmap, le bitmap comprenant des infor- 
mations indiquant que la deuxieme unite d'enregis- 
trement de donnees est invalidee. 

25. Procede de gestion d'un support d'enregistrement 
selon Tune quelconque des revendications prece- 
dentes, le procede comprenant en outre les etapes 
consistant a : 

lire, sur la base des donnees de ladite premiere 
table, ladite deuxieme table a partir des pistes 
pour donnees numeriques du support d'enre- 
gistrement (1) ; 

detecter (S42) des informations indiquant un 
bloc disponible a partir de la deuxieme table ; 
enregistrer des donnees numeriques dans des 
blocs des pistes pour donnees numeriques cor- 
respondant aux informations indiquant ledit 
bloc disponible ; et 

reecrire (S47) les informations indiquant ledit 
bloc disponible de la deuxieme table en infor- 
mations indiquant un bloc invalide. 

26. Procede de gestion d'un support d'enregistrement 
selon la revendication 25, dans lequel, dans le cas 
ou les informations indiquant un bloc disponible ne 



seraient pas comprises dans la deuxieme tables, le 
procede comprend les etapes consistant a : 

detecter (S43) une zone vide du support d'en- 
5 registrement (1 ) a partir des donnees de la pre- 

miere table ; 

enregistrer, dans la premiere table, des don- 
nees indiquant que la zone vide est destinee a 
servir de pistes pour les donnees numeriques ; 

10 et 

enregistrer (S47) des informations indiquant un 
bloc disponible dans la zone pour des donnees 
de la deuxieme table correspondant au bloc de 
la zone vide destinee a servir de pistes pour 

15 des donnees numeriques. 

27. Procede de gestion d'un support d'enregistrement 
selon la revendication 25, le procede comprenant 
les etapes consistant a : 

20 

lire, sur la base de la premiere table, les infor- 
mations indiquant la position de la deuxieme ta- 
ble enregistrees immediatement avant la 
deuxieme table ; 
25 lire la deuxieme table sur la base des informa- 

tions indiquant la position de la deuxieme table. 

28. Procede de gestion d'un support d'enregistrement 
selon la revendication 24, le procede comprenant 

30 en outre les etapes consistant a : 

lire les donnees numeriques des premieres uni- 
tes d'enregistrement de donnees destinees a 
subir la gestion par ladite premiere table a partir 

35 du support d'enregistrement (1) ; 

memoriser les donnees numeriques des pre- 
mieres unites d'enregistrement de donnees 
dans une memoire (16) ; 
actualiser au moins une partie des donnees nu- 

40 meriques des premieres unites d'enregistre- 

ment de donnees memorisees dans ladite me- 
moire (16) par des nouvelles donnees numeri- 
ques chaque deuxieme unite de moins que la 
premiere unite, qui est destinee a subir la ges- 

45 tion par ladite deuxieme table ; et 

enregistrer les nouvelles donnees numeriques 
des premieres unites comprenant les nouvelles 
donnees numeriques memorisees dans ladite 
memoire (16) sur le support d'enregistrement 

50 (1). 

29. Systeme pour I'enregistrement et/ou la reproduc- 
tion de donnees numeriques sur et d'un support 
d'enregistrement (1 ) respectivement, suivant le pro- 

55 cede selon I'une quelconque des revendications 1 
a 28, comprenant : 

des moyens d'enregistrement (3-6) pour enre- 
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gistrer une premiere table (TABLE DE GES- 
TION) pour gerer les donnees numeriques en- 
registrees dans une zone determinee dans les 
premieres unites d'enregistrement de donnees 
(CLUSTER) ; une deuxieme table (PAT; BIT- 5 
MAP) pour gerer les donnees numeriques dans 
ladite zone determinee qui sont enregistrees 
dans les deuxiemes unites d'enregistrement de 
donnees (BLOC) et comprenant des informa- 
tions sur le fait que des donnees numeriques 10 
ont deja ete enregistrees ou non dans les 
deuxiemes unites d'enregistrement de don- 
nees correspondantes ; et les donnees nume- 
riques sur le support d'enregistrement (1) ; 
des moyens de reproduction (3-6) pour repro- 1$ 
duire ladite premiere table, ladite deuxieme ta- 
ble et lesdites donnees numeriques enregis- 
trees sur le support d'enregistrement (1) ; 
des moyens de memoire (16, 17) pour memo- 
riser ladite premiere table et ladite deuxieme 20 
table ; et 

des moyens de commande (11, 12) pour com- 
mander les moyens d'enregistrement et/ou de 
reproduction (3-6), selon lesdites premiere et 
deuxieme tables. 25 

30. Support d'enregistrement comportant sur celui-ci 
une premiere table (TABLE DE GESTION) pour ge- 
rer les donnees numeriques enregistrees dans une 
zone determinee dans les premieres unites d'enre- 30 
gistrement de donnees (CLUSTER) ; une deuxie- 
me table (PAT; BITMAP) pour gerer les donnees 
numeriques dans ladite zone determinee qui sont 
enregistrees dans les deuxiemes unites d'enregis- 
trement de donnees (BLOC) et comprenant des. in- 35 
formations sur le fait que des donnees numeriques 
ont deja ete enregistrees ou non dans les deuxie- 
mes unites d'enregistrement de donnees 
correspondantes ; et des donnees numeriques tou- 
tes enregistrees suivant le procede. de gestion se- 40 
Ion I'une quelconque des revendications 1 a 28. 
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